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SPECIFICATION 



DOWNLOADING FILE RECEPTION PROCESS 



Field of the invention 

The present invention relates to a file reception 
process applied to an audiovisual data reproduction 
system. 

Background of the invention 

In the prior art, file reception processes 
comprising a first step, wherein the file(s) received are 
stored in memory in a file located in a temporary storage 
area, are known. Then, a specific procedure checks 
whether the file(s) received correspond to the file(s) 
expected. If this is the case, according to the type of 
file, the files received are copied to a specified 
permanent storage area. 

Objects and summary of the invention 

Therefore, the purpose of the present invention is 
to remedy the disadvantages of the prior art by proposing 
a file reception process no longer reguiring temporary 
file storage. 

This purpose is achieved by a process for receiving 
files sent by a central server to an audiovisual data 
reproduction system, managed by an operating system and 
linked to the server, by means of a data transfer link, 
characterised in that the process comprises: 

- a step consisting of initialising a link between 
the central server and an audiovisual data reproduction 
system, 

- a step consisting of storing files sent by the 
central server on storage means of the audiovisual data 



reproduction system, each file comprising specified 
information representative of the type of data contained 
in the file, 

- a step consisting of searching, for each file 
received, a specific reception function, this search step 
being carried out by means of the specified information 
representative of the type of data contained in the file, 

- a step consisting of processing each file by the 
corresponding reception function, the processing 
comprising copying of the file received to a specified 
storage area . 

Brief description of drawings 

The invention, with its characteristics and 
advantages, will be understood more clearly upon reading 
the description given with reference to the appended 
drawings , wherein : 

- figure 1 represents a logic diagram of the file 
reception process according to the invention, 

figure 2 represents a logic diagram of a 
representative song file reception function, 

figure 3 represents a logic diagram of a 
representative album cover file reception function. 

Description of the preferred embodiments 
The file reception process according to the 
invention is implemented by an audiovisual data 
reproduction system such as that described in the 
European patent application No. 99 401 785.3. According 
to this European patent application, the reproduction 
system essentially comprises a central processing unit 
managing, by means of a plurality of interfaces and an 
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operating system, sound reproduction, image display, song 
selection and a link with a remote audiovisual data 
distribution server. The operating system is organised in 
hierarchical modules each managing a specific function of 
5 the audiovisual data reproduction system. 

The operating system of such an audiovisual data 
reproduction system also manages a database. This 
database contains data on the files stored on the 
reproduction system's storage means. These files 

10 particularly represent, either digitised data forming 
songs, or graphic data representing the cover of the 
albums from which the songs are taken, or animations 
(video or advertising) , For example, there are at least 
two types of graphic files. The first type of graphic 

15 file represents the album cover in a small format. This 
first type of graphic file is used during a customer's 
search in the list of songs available on the reproduction 
system. The second type of files represents the album 
cover in a large format. This second type of file is used 

20 when the customer has selected a song taken from the 
album corresponding to the cover. The third type of file 
may be a video, advertisement or survey. The different 
file types, song files, graphic files of the first and 
second types, are differentiated using a different file 

25 extension for each file type. 

The data contained in the database is used to 
determine the links existing between the song files and 
the associated graphic files, such that all song files 
are linked to at least one graphic file. However, graphic 

30 files representing the album cover may not be linked to 
any song file. This means that the songs in the album 
represented by the cover are not stored on the 
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reproduction system but may be ordered in order to be 
downloaded onto the reproduction system's storage means. 
Similarly, new songs with their corresponding album 
sleeve may be ordered in order to be downloaded onto the 
5 reproduction system's storage means. It is during the 
downloading of the files corresponding to the songs or 
album sleeves that the process according to the invention 
is implemented. 

When new songs are ordered using an audiovisual data 

10 reproduction system, the operating system of the 
reproduction system checks whether, for the new song, a 
graphic file, representing the album cover, is already 
stored on the storage means. If this is not the case, the 
corresponding graphic file(s) is/are also ordered. For 

15 each file ordered, a function intended to process and 
handle the file ordered is created by a module of the 
operating system supervising the type of file ordered. In 
this way, the operating system comprises a first module 
managing song files, a second module managing the first 

20 type of graphic files, a third module managing the second 
type of graphic files and other modules managing the 
other file types. In the rest of this document, the 
operation will be described with three different file 
types. However, this does not represent a limitation of 

25 the present invention. In this way, during the order, for 
example of a specified song file, the first module 
creates a specific reception function for the song files 
ordered. To do this, the database comprises the name of 
all the files of all the songs available on the 

30 reproduction system and the name of all the files of all 
the downloadable songs. In this way, for each file 
ordered, the reception function is created. 
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Similarly, the first, second and third modules 
comprise a function creating a "standard" reception 
function used to account for the reception of a song file 
or a graphic file of the first or second type. In this 
5 way, even if a file, e.g. a song file, was not ordered 
directly by means of the reproduction system, but by 
other means such as, for example, the server or an 
Internet site connected to the server, the reception of 
this file may be taken into account by the reproduction 
10 system. 

When the order of a file has been validated, a 
fourth module of the operating system handles the 
management of the link with the remote server. For this, 
as soon as a communication is connected with the server, 

CO 

j^fi 15 the fourth module creates a specific file comprising the 

identification of all the files ordered on the 
Q reproduction system. After the server checks any rights 

authorising the downloading of files onto the 



reproduction system or not, the requested files are sent 



Q 

Q 20 to the requesting reproduction system. The files are sent 

in data packets. 

Figure 1 represents a logic diagram of the file 
reception process according to the invention. In the 
process according to the invention, a first step 10 

25 consists of initialising the communication between the 
server and the reproduction system to perform the file 
transfer. Then, the process comprises a step 11 
consisting of opening a reception file on the storage 
means. According to the invention, the storage area 

30 selected is a permanent storage area wherein the memory 
available has a specified minimum size. In this way, 
unlike the prior art, the data is not stored in a 



specific temporary storage area, but in any area of the 
storage means, provided that this area has a specified 
minimum size. After the file has been opened, during a 
third step 12, a "telecommunication" module of the 
operating system, is set to standby for a data packet. 

Then, during a reception step 13, the data contained 
in the packet received is copied to the open file. A 
checking step 14 checks whether the packet that has just 
been copied is the last packet of the file being 
received. As long as the last packet of the file being 
received has not been received, all the data packets of 
the same file are copied to the previously opened file. 
When the last data packet of the file is detected during 
the checking step 14, the operating system 
telecommunication module creates, during a sixth step 15, 
a notification that it then sends to the fourth module 
managing the link with the server. This notification 
informs the fourth module that a new file has been 
received. As soon as this notification is received, the 
fourth module switches from a standby step 20 to a search 
step 21 in all the reception functions created, to find 
whether any of them relate to the file received. 
Similarly, the fourth module also searches to find 
whether a standard reception function exists. 

The search is carried out by means of the name of 
the file received and/or by means of its extension. 
Indeed, each reception function is specific, either to a 
specific file or to a file type. Consequently, using the 
name or extension of the file received, the associated 
reception function can easily be located by the fourth 
module. When the fourth module locates the function 
corresponding to the file received, it is then activated 



during a ninth step 22 to start the processing of this 
new file. For each file related to a song, a first 
reception function is activated during a tenth step 24, 
and for each file related to an image, a second reception 
function is activated during an eleventh step 23. The 
processing of a song file or image file essentially 
consists of copying the file received to an appropriate 
memory area and then updating the reproduction system's 
database. If no reception function is located by the 
fourth module of the reproduction system, the process is 
stopped and no other action or operation is carried out 
on the file received. 

Figure 2 represents the logic diagram of a 
representative song file reception function. In a first 
step 30, the reception function checks in the 
reproduction system's database whether the file already 
exists. If it exists, the new file is copied over the old 
one in a second step 31, such that the old file is 
deleted, if the file does not exist, the new file is 
stored in memory, in a third step 32, to an appropriate 
area of the storage means, e.g. to a specific directory. 
Then, the function checks, in a fourth step 33, whether 
the new file was copied correctly. If this is not the 
case, the function, in a fifth step 302, deletes the file 
received. If the new file was copied correctly, the 
reception function updates the database. This update 
comprises, in a sixth step 34, a search in the file 
received, for the data to update the database. Then, 
using the data found, the reception function checks, in a 
seventh step 35, that the associated graphic files exist. 
Similarly, the reception function checks whether the 
versions of the song file and associated graphic files 
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are compatible with each other and with the operating 
system version. Otherwise, the operating system is not 
updated or the new graphic files are ordered, for 
example, according to the process described in the 
European patent request No. 99 401 785.3. 

Then, in an eighth step 36, the reception function 
updates the database to account for the associated 
graphic files. In a ninth step 37, the reception function 
adds to an event table in the reproduction system's 
database that a new song file has been received. 

In a tenth step 38, the reception function updates a 
file stored on the reproduction system, comprising the 
identification of all the songs available on the 
reproduction system. Each song is, for example, 
identified by means of a single number. This file is used 
by the server to detect the list of songs available on 
each reproduction system connected to the server. In this 
way, the server can detect the list of songs present on 
the reproduction system by requesting, during a 
communication with the reproduction system, the latter to 
send the file containing the list of songs. In this way, 
the server simply needs to extract the song numbers 
contained in this file to find out the songs available on 
the reproduction system. 

In an eleventh step 39, the reception function adds 
an entry to a statistics table in the reproduction 
system's database. This statistics table makes it 
possible to determine how many times the song 
corresponding to the new file received is selected. In a 
twelfth step 301, the reception function updates a 
purchase table in the reproduction system's database. 
This purchase table is used, for example, to check that 
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the number of songs ordered is less than a specified 
number or to bill the songs ordered. Then, the reception 
function carries out the fifth step 302 consisting of 
deleting the file received at its original location, 
5 Indeed, the file received in the second 31 or third step 
32 is copied to a specified memory area. Consequently, 
the file received is kept in its initial location 
throughout the database update steps. After this update, 
the initial version is of no further use and, 

10 consequently, may be deleted. The reception function ends 
with a thirteenth step 303 consisting of updating the 
number of songs that can be selected by a customer on the 
reproduction system. This number is stored in memory on 
the system storage means to be compared to a specified 

15 threshold. When the number is equal to the threshold, 
this means that the reproduction system comprises a 
maximum number of songs that can be selected and that it 
is therefore not possible to order others without 
deleting at least one song beforehand. 

20 Figure 3 represents the logic diagram of a 

representative album cover file reception function. 
According to the invention, the processing of graphic 
files of the first and second types is identical. The 
graphic file reception function checks, in a first step 

25 40, the integrity of the file received. In a second step 
41, the reception function checks in the reproduction 
system's database whether the graphic file already 
exists. If it exists, the new file is copied, during a 
third step 42, over the old file, such that the old file 

30 is deleted. If the file does not exist, the new graphic 
file is copied, during a fourth step 43, in an 
appropriate area of the storage means, e.g. to a specific 
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directory. Then, the function checks, to a fifth step 44, 
whether the new file was copied correctly. If this is not 
the case, the function, in a sixth step 46, deletes the 
file received. If the new file was copied correctly, the 
reception function, in a seventh step 45, updates the 
database. This update consists of indicating the name of 
the new graphic file, and the songs to which it is 
linked, i.e. the songs belonging to the album represented 
by the graphic file. All this data is either available in 
the graphic file or available in an archive table in the 
database . 

In this way, the file reception process according to 
the invention is characterised in that it comprises: 

- a step consisting of initialising a link between 
the central server and an audiovisual data reproduction 
system, 

- a step consisting of storing files sent by the 
central server on storage means of the audiovisual data 
reproduction system, each file comprising specified 
information representative of the type of data contained 
in the file, 

a step consisting of searching, for each file 
received, a specific reception function, this search step 
being carried out by means of the specified information 
representative of the type of data contained in the file, 

- a step consisting of processing each file by the 
corresponding reception function, the processing 
comprising copying of the file received to a specified 
storage area. 

In another embodiment, the storage step consists of 
opening a file in any permanent memory area with an 



available area of a specified minimum value, to write the 
data sent. 

In another embodiment, the processing step comprises 
the update of a database of the audiovisual data 
reproduction system to account for the data contained in 
the file received. 

In another embodiment, the search step is activated 
when the last data packet corresponding to a whole file 
is stored in memory. 

In another embodiment, the specified information 
comprises the file extension and/or the name of the file 
received . 

In another embodiment, when the specified 
information represents a song file, the database update 
step comprises at least one of the following steps: 

- a step consisting of checking the compatibility of 
the version of the song file with the version of the 
reproduction system operating system, 

- a step consisting of updating a file stored on the 
reproduction system containing the identification of all 
the songs stored on the reproduction system, 

- a step consisting of updating a statistics table 
in the database making it possible to determine the 
selection frequency of the song corresponding to the file 
stored in memory, 

- a step consisting of updating a purchase table 
containing the number and name of all the songs purchased 
for the reproduction system, 

- a step consisting of updating a counter of songs 
that can be selected to check that the number of songs 
that can be selected is not greater than a specified 
threshold. 



It must be clear for those experienced in the art 
that the present invention enables embodiments in many 
other specific forms without leaving the field of the 
invention as claimed. Consequently, the present 
embodiments must be considered as illustrations, but may 
be modified in the field defined by the scope of the 
claims attached, and the invention must not be limited to 
the details given above. 



